Web Application Pentesting

Tags: #◇Computer Science #◇NSSECU2 #◇Cybersecurity #◇Web Security #◇Burp Suite #◇OWASP #◇SQL Injection #◇XSS #◇IDOR

◇Overview

Web applications represent the most exposed, feature-dense component of an organization's public perimeter. Web application penetration testing combines protocol-level HTTP analysis with manual request tampering to identify logic flaws, broken access controls, and injection vulnerabilities that automated scanners overlook. Utilizing intercepting proxies—primarily Burp Suite—security analysts manipulate client-side requests, inspect server responses, and evaluate how backend servers process untrusted user input against the OWASP Top 10 vulnerability taxonomy.

◇Key Definitions

• Intercepting Proxy: A specialized intermediary tool positioned between a client browser and a target web server that captures, logs, and allows manual or automated tampering with HTTP/HTTPS traffic.
• Burp Suite: The industry-standard web application security testing platform developed by PortSwigger, featuring Proxy, Repeater, Intruder, Decoder, and Sequencer modules.
• Insecure Direct Object Reference (IDOR / BOLA): A broken access control flaw where an application uses user-supplied input to access database objects directly without validating whether the requesting user possesses authorization for that specific record.
• SQL Injection (SQLi): An injection vulnerability occurring when untrusted user input is directly concatenated into dynamic SQL queries, allowing an attacker to manipulate database execution, bypass authentication, or extract sensitive data.
• Cross-Site Scripting (XSS): A client-side code injection flaw where an attacker injects malicious JavaScript into a web application, which is subsequently executed within the browser of a victim user.
• Command Injection: An operating system injection flaw where an application passes unfiltered user input directly to a system shell execution function (e.g., system(), exec(), passthru()), granting the attacker arbitrary OS command execution.
• Burp Repeater: A manual testing tool within Burp Suite designed to modify and re-send individual HTTP requests repeatedly to observe subtle response differences.
• Burp Intruder: An automated parameter fuzzing engine within Burp Suite used for password brute-forcing, directory enumeration, and identifier cycling.

◇Theoretical Framework / Core Concepts

1. Intercepting Proxy Architecture

All web penetration testing relies on routing browser traffic through a local proxy listener:

1. Proxy Listener: Browser network settings are configured to route all HTTP/S traffic through 127.0.0.1:8080.
2. CA Certificate Installation: PortSwigger's custom root CA certificate is imported into the browser trust store to permit transparent SSL/TLS decryption (HTTPS inspection).
3. Traffic Analysis: Every request and response is archived in the HTTP History tab for passive analysis.

2. Anatomy of an HTTP Request & Response

Understanding raw HTTP protocol mechanics is essential for manual tampering:

POST /api/v1/user/update HTTP/1.1
Host: target.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0)
Accept: application/json
Content-Type: application/json
Content-Length: 48
Cookie: session=eyJuYW1lIjoiYWxpY2UiLCJyb2xlIjoidXNlciJ9

{"user_id": 101, "email": "alice@target.lab"}

• Request Line: Method (POST), Resource Path (/api/v1/user/update), Protocol (HTTP/1.1).
• Headers: Metadata instructions (e.g., Host, User-Agent, Content-Type, Cookie).
• Body: Data payload (JSON, URL-encoded form data, XML, or multipart binary).

3. Burp Suite Tool Ecosystem & Attack Modules

◇Web Vulnerability Testing Protocols & Attack Vectors

1. Insecure Direct Object References (IDOR)

IDOR occurs when an application exposes a reference to an internal object in a request parameter without verifying authorization:

================================================================================
BASELINE REQUEST (USER 101 LOGGED IN):
================================================================================
GET /api/documents?doc_id=1010 HTTP/1.1
Host: target.com
Cookie: session_token=USER_101_SESSION

HTTP/1.1 200 OK
{"document_name": "Alice_Resume.pdf", "owner": "alice"}

================================================================================
TAMPERED REQUEST (TESTING USER 102'S DOCUMENT):
================================================================================
GET /api/documents?doc_id=1011 HTTP/1.1
Host: target.com
Cookie: session_token=USER_101_SESSION

HTTP/1.1 200 OK
{"document_name": "Bob_Confidential_Salary.pdf", "owner": "bob"}

CONCLUSION: IDOR vulnerability confirmed! User 101 can access User 102's private files.

2. SQL Injection (SQLi) Testing

SQL injection occurs when user-supplied input alters the logical structure of a database query:

-- Vulnerable Server-Side Query Construction (PHP/MySQL):
$query = "SELECT * FROM users WHERE username = '" . $_POST['user'] . "' AND password = '" . $_POST['pass'] . "'";

-- Injected Payload in Username Field:
admin' OR '1'='1' -- 

-- Resulting Server Query (Authentication Bypassed):
SELECT * FROM users WHERE username = 'admin' OR '1'='1' -- ' AND password = '...'

SQL Injection Taxonomy

• In-Band SQLi: Data is extracted through the same channel used to inject (Error-Based, Union-Based).
• Inferential (Blind) SQLi: No data is directly returned on screen; results are inferred through Boolean true/false page differences or Time Delays (SLEEP(5)).
• Out-of-Band SQLi: Data is exfiltrated via DNS or HTTP requests triggered by the database daemon (xp_dirtree, UTL_HTTP).

3. Cross-Site Scripting (XSS) Testing

XSS occurs when unencoded user input is rendered in the victim browser's DOM:

4. Operating System Command Injection

Occurs when web applications pass user input directly to server shell functions:

# Example Vulnerable Web Function (Ping Utility):
# Backend Code: system("ping -c 1 " . $_GET['ip']);

# Normal Request:
GET /ping?ip=8.8.8.8

# Malicious Injected Requests:
GET /ping?ip=8.8.8.8;id
GET /ping?ip=8.8.8.8%20%26%26%20whoami
GET /ping?ip=8.8.8.8|cat%20/etc/passwd
GET /ping?ip=$(id)

◇Evidence Logging & Reporting Discipline

Documenting web vulnerabilities requires pairing the exact raw HTTP request with the corresponding server response:

================================================================================
WEB VULNERABILITY EVIDENCE RECORD
================================================================================
Vulnerability:       Reflected Cross-Site Scripting (XSS)
Target Endpoint:     http://192.168.10.45:8080/search.php
Parameter:           `keyword`

Raw HTTP Request (Burp Repeater):
GET /search.php?keyword=%3Cscript%3Ealert(%27XSS_POC%27)%3C/script%3E HTTP/1.1
Host: 192.168.10.45:8080
User-Agent: Mozilla/5.0 (X11; Linux x86_64)

Raw HTTP Response:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

<div>Search results for: <script>alert('XSS_POC')</script></div>

Technical Analysis: The server reflects the `keyword` parameter verbatim without
                    HTML entity encoding or Content Security Policy (CSP) headers.
================================================================================

◇Defensive Architecture & Remediations

• Context-Aware Server-Side Authorization: Never rely on client-side parameters for access control. Validate that current_user.id == requested_object.owner_id on every backend database query.
• Parameterized SQL Queries (Prepared Statements): Completely separate SQL code structure from user data.
  『』

  PHPCOPY

  // Secure Prepared Statement (PHP PDO)
  $stmt = $pdo->prepare('SELECT id, name, email FROM users WHERE username = :user AND password = :pass');
  $stmt->execute(['user' => $username, 'pass' => $hashed_password]);
  

• Contextual Output Encoding: Encode all dynamic user input before inserting into HTML (htmlspecialchars), JavaScript, or attributes.
• Content Security Policy (CSP): Restrict inline script execution using strict CSP headers (Content-Security-Policy: default-src 'self'; script-src 'self').

◇References & Navigation

• Previous Topic: ◇Authentication Weakness Testing
• Next Topic: ◇Exploitation Workflow with Metasploit
• Related Notes: ◇Authentication Weakness Testing, ◇Exploitation Workflow with Metasploit